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ABSTRACT 


This thesis provides a critical analysis of the Navy's 
Message Processing and Distribution System (MPDS) develop- 
ment.A historical approach is used in presenting the 
system's life cycle development beginning with the planning 
phase and ending with the integrated logistic support phase. 
Several maintenance problems which occurred after the systen 
was accepted for Flest use war2 examined to determine 1 
they resulted from errors in the acquisition process. The 
Gmaerlying intent of the thesis is to use the MPDS to exa- 
mine the critical decision points of the acquisition process 
eee Offer constructive recommeniations for avoiding tke 
problems which hindered the successful development of this 


system. 
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Ls LN TRODUCTION 


Iie purpose Of this thesis is to analyze the pertinent 
aspects of development and life cycle support of the Navy's 
Automated Message Processing and Distribution System (MPDS). 
The historical section will discuss the imperative need to 
automate the Navy's communication systems. Pew vlil then 
explain the Navy's decision to begin developmental effort to 


automate many of the manual communications functions. 
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The development of the MPDS will next ke discussed 


detailed emphasis placed on the following topics: 


1. Hardware Specifications 
Ze software Specifications 
3. Security Requirements 
Pmemcontiguration Control 


5. Testing Procedures 


Next, a few unique problems with system maint2nance, logis- 
[wemsupport, and training will also be examined. 

Finally, cause/feffect conclusions will be drawn and 
coupled with constructive recommendations for future major 


system development projects. 


ieee kOmner His TORY 


A. BASELINE II COMMUNICATIONS STODY 

In October of 1966, the Command2r of the First Fiset con- 
ducted a Communications Readiness Exercis2 to determine the 
Fleet's ability to handle large volumes of message traffic 
during Simulated wartime conditions. This exercise was 
known as Baseline II, and it revealed the fleet wa 
to handle large message volumes without encountering siani- 
ficant delays. These delays usually occurred in areas whers 
humans were reguired to manually handle or process <he mes- 
sages. Two of the areas where major delays frequently 
occurred were identified as the Naval Communication Stations 
(NAVCOMSTAS) and Radio Central on board the naval ships. 

The Naval Electronics Laboratory Center (NELC) ig San 
Diego was directed to develop a system which would reduce 
the shipboard delays in message processing and distribution. 
The objective was to automate as many manual functions as 
possible. NELC installed the first experimental shipboard 
Message Processing Distribution System (MPDS) aboard the USS 
Oklahoma City (CG-5). This initial system was quite smail 
and consisted of a single processor, magnetic disk storage 
device, and a high speed printer. Many updates and ¢nhance2- 
ments wer addedto this system as they became avaiiadle. 
Several remote printers wera Later installed at important 
no attempt was made to 


[eeacions throughout the ship, b 
add remote interactive terminals ( 


= 
ef. 1) Consequently, all 
outgoing message traffic had to be physically deposited at 


Radio Central for transmission from the ship. 


B. CVN-68 MESSAGE PROCESSING AND DISTRIBUTION SYSTEM 

At the same time that NELC was working on the CG-5S MPDS, 
it began work on the fully automated MPDS destined for ins- 
wotlation on the USS Nimitz (CVN-68). This system was to bs 


part of the ship's original equipment, so it was extremely 


mmpertant that the project's completion dat 
euesely t5 the completion of construction of th 
MPDS not been ready and available on time, the Nimitz wo 
have been forced to go to sea with an e2xtrem 
Manual communications systen. Consequently, pro 
ment of the system's development by NELC was 
importance if the Navy's readiness objectives 
obtained. 

The Nimitz was originally scheduled to come out of con- 
struction in late 1973, but reactor delivery slippage caused 
several delays which resulted in a late commissioning in 
1975. Since the MPDS was behind schedule, the deiivery dats 
Slippage for the reactors gave WNELC and Planning Research 
Company (PRC) badly needed additional time to correct sev- 
eral software problems and install the completed systen 
@ioeatrd the Nimitz in 1974 without causing any further 
delays. “Ref.2] 

ieee used the old airéraft carrier, USS Bunker Hill, to 
test the operation of MPDS ina shipboard environment [ Ref. 
Beer his procedure provided NSLO with the opportunity to 
examine the effects of the shipboard electricity, excess 


humidity, and metallic influence upon the MPDS. 


C. MAINTENANCE PHASE 

In 1975 the Fleet Gombat Direczion System Stppozt 
Activity, San Diego, (FCDSSASD), assumad system sipport 
Becponsibility for MPDS. QIEL Ng the following Eive years, 
eighteen major changes were approved and releasel which 


affected one or all of the following major systems: 


1. Operating System (0S) 

2. Software Maintenance System (SNS) 

3. Equipment Maintenance Sub-system (=MSS) 

4. System Magnetic Tape Retrisval (SMR) 
PRets 4} 


In 1976, the Navy awarded the MPDS software maintenance 
Beemacte £5 Syncrotech Software Corporation in San Diego. 
Maes contract was “soles source’ and went to Syncrotech 
because they employed a great number of PRC programners who 


were involved in the initial davelopment of MPDS [ Ref. 5). 


D. ADDITIONAL INSTALLATIONS OF MPDS 

An identical copy of MPDS was later installed aboard the 
USS Eisenhower (CVN-69), and a copy is presently being 
installed aboard the Vinson (CVN-70). Pi uiueeeeOr Toys, in 
response to the Chief of Naval Operations, the Naval Elec- 
tronic Systems Command began a project called the Naval 
Modular Automated Communications Systen (NAVMACS). Since 
NAVMACS was designed to fulfill the communication needs of 
ali Naval ships and the carrier version NAVMACS V-5 will 
soon be completed, no additional copies of MPDS will be pro- 
@meead for future carriers. NAYSEA has also authorized the 
installation of the NAVMAC V-5 system to replace the MPDS 
onboard the USS Nimitz, USS Eisenhower, and the Vinson as 


these ships enter their regular overhaul cycles. 
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IIL. ANALYSIS OF MPDS DEVELOPMENT PROCESS 


| a ig: tag OE Aaya A a 


A. HARDWARE SPECIFICATIONS 


1. Available Hardware 


The initial specifications reguired that the project 
office "utilize equipment units or designs which are in 
being and readily available"{Ref. 6}. A list of available 
equipment follows: 


Name Designation 
Senvral Processor CP-642B 
Magnetic Disk RD-281 
Magnetic Tape UJnit (HTU) RD-294 


The decision to use available equipment offered the 
possible advantage of reducing development cost because it 
is much cheaper to purchase additional units than it is to 
@develop the initial units. It also helps to improve the 
Navy's Supply System Purchasing Office's economies of scale 
Since it serves to increase the overall purchase volume. 
This procedure also conforms to the Department of Defense 
Standardization Program which requires the services to pur- 
chase existing equipment. Using existing equipment involves 
less risk, so it helps prevent cost overruns and schedule 
Slippages. It also lessens the logistic probiems which are 
generally asscciated with unique equipment items. Items 
which are already in the Navy stock system often have 
maintenance contracts established with the vendors. eo a 
tunately, buying existing egquipaent did not solves MPDS's 
logistic problems because the manufacturers of many of these 
vendors stopped producing the equipment. Therefore 
replacement has become increasingly difficult and equipment 
overhauls have become longer and more costly. 

2. Yardware Development Items 
Many hardware items which were required for MPDS 


were not available in the naval stock system and had to be 
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contracted out for development. Several of the major equip- 


ments which had to be developed include: 


Name Designation Contractor 
Line Printer TY e249 Data Products 
Magnetic Drum oes 7 0 RCA 
Display Keyboard ZB Ge) Burroughs 


fhe Data Accumulation and Distribution Unit (DADU) 
was a very sophisticated and unigue piece of hardware which 
was developed to perform the system muitiplexor funcztion for 
MPDS (Ref. Peete sieGeronie §~SWitECHIng Unit (ESU) was 
another unit which had to be developed +9 allow ali three 
processors access to the magnetic disk. The ESU has proven 
to be very reliable, but its failure would restrict two of 
the thre2 processors from accessing the single disk. The 
ONI~43 is a device used to interface MPDS with the fleet 
satellite broadcast, Common User Digital LNforhacion 
Exchange Subsystem (CUDIX). This device was developed aftar 
MPDS was accepted for fleet use, and it became apparent that 
MPDS required a backup system which would provide broadcast 
support during periods of major squipment failures. 

SB. Eguipment Specifications 

General requirements for all equipment developed for 
MPDS are referenced in the specification document [R2f. 8}. 
Military standards were referenced which set equipment 
requirements for temperature, shock, resistance, low level 
Signaling and reliability [Ref. 9]. Functional spscifica- 
tions for the hardware included processing rates required, 
code which it must be capable of processing, security 
requirements, and other general functional reguirements. 

4. Areas Not Specified 

Difficulty meeting several of the original specifi- 

cations arose because the Navy was setting standards for new 


equipment which was destined for shipboard use and had to 
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Pemeerm EUNCtIONS which had not existed prior to ta 
EEO ject. Consequantly, numerous changes were proposed and 
made to the original specifications as the program effort 
progressed and the contractors experience improved in the 
new development. 

Many of the items which ware developed for the pro- 
feGesclearly lacked detailed specifications, so it was left 
to the personnel in the program office and the contractors 
to work out the details. The cesult was a descriptior of 
what had been built rather than a specificazion of what was 
to be developed [Ref. 10]. Back G2 Sdeci fications oficred 
the advantage of allowing the program office and contractors 
the opportunity to make important changes to the system's 
design Wana ch frequently resulted in improved systen 
performaice. 

Ine change which improved system operation was the 
Mmemwecation of terminals in Radio Central. Originally, two 
terminals were to be used for control and placed at the con- 
trol console with another terminal placed in a maintenance 
area. The program office altered the arrangement by placing 
all three terminals at the control console, and this greatly 
improved the reliability of the control system because the 
AN/UYA-9 terminals have experienced a low mean ti 
failure (MTBF) and a high mean time to repair (MT 
ill. 

bdiek Of Specliications also had many obvious disad- 
vantages. PNR Olen GlettCUlL. “LOr the contractor and 
program office to know when a development was actually fin- 
ished because they had nothing to compare the ‘finished 
meeaduct ajainst [Ref. 12]. It proved to be a problem with 
the program sponsors because they would complain ‘that "the 
Navy was not getting what it originally asked for" [Ref. 
Sj. Allowing the project office the freedom to design the 


system where Specitications did not exist tended to 
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eieourage configuration confusion. It is vitally important 
that a clear design pattern be outlined in the specification 
to prevent the developmental effort from wandering off 
course, A detailed initial set of specifications would 


have resolved this conflict. 


PemPOOEITWARE SPECIFICATIONS 

The original specifications required all software to be 
Pwoouter in design such that addition, deletion, or change 
of function be made with a niniaum of reprogramming" [ Ref. 
14]. The requirement that the software be modular in design 
was fulfilled by the contractors. However major problens 
with adding modules and changing functions have occurrad 
during the maintenance phase because of excessively high CPU 
@one Utilization. The specifications did not set utiliza- 
tion limitations upon the amount of core which the programs 
were permitted to consume. Th] requirement for the contrac- 
tor to meet performance specifications did serve to limit 
the amount of core which should be used and still meet per- 
formance objectives, but allowances were not made for future 

growth and program enhancements {Ref. 15]. 

1. Manual Security Measures 

The Informational Security System Design for MPDS 
waS extremely important because MPDS completely changed the 
Beeuccre of shipboard message handling and this created 
humerous n¢éw security concerns. PELOE vO IPDS, SECUrity was 
und 


provided by the thick metal and heavy security doors aro 
Radio Central. Distribution security was accomplished by 


restricting access to those individiuals who were designated 
in writing by their department heads. An up-to-date list of 
these personnel with their names, security clearances, and 
the highest level of message classifications that they were 
authorized to receive was continuously maintained at radio 
central. This listing was checked any time an individual 


requested message distribution. 
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2. Automated Security Measures 
Raper yS,emonesmethod of providing additicnael pro- 
tection which was identified in the specifications was 


Coded device which would be us2=d 2t the remote terninals 


(Oy it 
lay 1) jw 


inform the control console of the classification level 
the terminal [Ref. 16]. A security card reading device was 
never developed, but a manual code entry device was devel- 
oped whereby the user could type in his classification code 
and have messages and reports distributed to his terminal at 
the appropriate classification level. 

The project Office was afforded considerable lati- 
tude in ieveloping a software system which was able to check 
the validity of the codes enter2d at the terminals. An 
operating syst2m security module was developed which con- 
pared the code of the user toa Master Security List (MSL). 
The MSL contained a listing of all the authorized users, 
their codes and the levels of security which they were 
cleared +o access [Ref. i The specifications also 
required special acknowledgement for receipt of top secret 
materials. Additionally, the completed MPDS provided a top 
secret disclosure sheet to assist the authorized recipient 
in maintaining tight controi over the sensitive document. 

See 2perating System Security Options 

Unfortunately, the projects software specifications 
did not address in detail several other new security con- 
cerns which were encountered in the new message handling 
systen. Ine critical aspect of the software development 
which was not addressed specifically was the security pro- 
tection to be provided by the operating systen. Since 
Operating systems vary widely in the amount of protection 
mien =hey provide for their data, it is prudent to specify 
the exact features that are desirable to be includéd in the 


System to be developed. 


IBM marketed a protection mechanism in its operating 
systems called "locks" which served te prevent unauthorized 
read/write accesses to secure blocks of memory. TBM also 
used the supervisor/problem nod to distinguish between 
users and executive states. This differentiation helped 
prevent unauthorized alterations of instructions, storage 
protection locks, and the operating system (Ref. 18]. 

The Multics operating system which was developed by 
Honeywell Information Systems offered one of the nmnost 
advanced security systems in production. It offered several 
Sophisticated features which were not available on IBM Sys- 
tems. Ine important component was the internal password 
encryption which served to prevent illegal disclosure of the 
master password list. This protection was accomplished by 
encrypting the password which the user ent2red and comparing 
it against the internal password file. Therefore if a sub- 
versive agent were able to gain access to the computer and 
captur2 the internal password file, it would be of little 
value to him without the encryption code. A second impor- 
tant aspect of the Multics Security System was the use of 
audit trails to keep a record of the users who accessed the 
classified data. (Ref. ol. This procedure is extremely 
effective when the users review the audit trail on a regular 
basis and compare it against their access logs. 

4. System Vulnerability 

S-Clameyesat=guards acs particularly important ina 

multiprogramming/multiprocessing environment where <+he pro- 


cessors are required to handie multiple processes at the 


same ‘tine, These? processes will usually have different 
security values and will be Sharing the same systen 
resources. A system or device which can guarantee complete 


isolation and protection of the secure process from unau- 
thorized access or disclosure has not been developed. Even 


the Multics system which was designed with security as one 
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of its primary objectives was penetrated by a special U.S. 
Air Force Tiger Team who was tasked to assess the security 
of the computers used by the Air Force. Security patches 
were used to correct the security weaknesses which were dis- 
covered by the team, but these patches didn't prevent the 
Tiger Team from making additional penetrations by exploiting 
other system weaknesses [Ref. 20]. 

Attempts to upgrade the existing level of MPDS security 
to include some of the features present in NULTICS would be 
extremely costly and would not guarantee the security of the 
system. Since it is difficult to upgrade security, a pEo- 
Geam’sS sponsor must be very explicit in stating in the 
System specifications the type of security protection that 


is wanted. 


C. CONFISURATION CONTROL 

mee rcs Specification 
Phe control of system configuration proved to be one 
memene MOSt dirficult problems confronting the program off- 
age .S The lack of precise specifications was one of the 
Meee creasons for uncontrolled growth in the Facility Con- 
mol, System (FCS). Tieme eet y “Speci fieation for the 
Message Processing and Distribution System for (CVAN-68) 
dated 30 Jan. $1967 tequired the following monitoring 


capabilities: 


Bezeie'1 A Continuous or periodic indication of suspected 
channel trouble shall be provided to the Facility, Control 
Console for those channels being processed automatically. 


The Specifications also provided the follow guidance on how 


FCS will interface with MPDS. 


3.2.1.10 The interface between the MPDS central processor 
and the FCS circuit sensing multiplexer, to, provide for 
moe ot fhe Communication Circuit sensing signals to the 
MPDS central processor, Will be a standard I/O channel of 
the central processor. 
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HeEmGONp Vey he the aOOVe Guidance, the project off- 
Mmeemmara contractor were forced tc decide what <ype of 
sensing nechanism would be used ¢*0 monitor or interrogate 
the channels and how often the sensing should take place. 


Semce both the contractor and the project office wanted th 


rt) 


best system for the Navy, they frequently elected to develop 
a system which offered high performance as opposed to a less 
elaborate system whith offered narginal performance at a 
smaller cost [Ref. 21]. Many other decisions had to be made 
concerning "how to fulfill the specifications" and these 
eventually caused the FCS to grow in size, time, and cost. 

The completed FCS would have provided many benefits 
eoameeene Ship's communication personnel for it would have 
greatly ceduced the amount of manual operator intervention 
reguired for channel and terminal connections. [te also 
would have provided an increased quality control capability 
which has been desired for a long time by fleet communica- 
tion users. 

Despite the recognized advantages in operator ccst 
reductions and improved system reliability, the development 
Sree cs by NELC had to be cancelled by NAVELEX because it was 
exceeding the original estimates for cost, resource utiliza- 
ton, and date for delivery [Ref. 22'}. The amount of code 
and its corresponding core requirements had grown to such a 
degree that it was estimated that the completed FCS project 
would have reguired additional CP-642B central processing 
units if MPDS was to continue to meet the original perfor- 
mance specifications. 

It should also be noted that the implementation of 
FCS would not have significantly improved MPDS' message dis- 
tribution capabilities nor would it have increased the 
System's processing speed. The primary advavtages of FCS lie 
Baeic’S improved guality monitoring and reduction in t 


number of operators required to manage the system. Since the 
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Beamery objective of MPDS was to correct the shipboard 
communication deficiencies of slow message handling and poor 
message distribution which were revealed during the Baseline 
Peemeommun: Cations Study, it is apparent that the FCS could 
only be viewed as desireable excess feature. 
Pee Feasibility Study 
a. General Approach 

Pier unsenOr 119/705, Planning Research Company 
(PRC), who was NELC's software contractor for MPDS, did an 
Intergration of Communication System Study which included a 
QWUality Monitoring Trade-off Stuiy. The we GOal Of the study 
was to determine the feasibility of integrating an Automatic 
Quality Monitoring System (AQMS) and a Frequency Honitoring 
Seeoeem (FMS) with MPDs. AQMS and FMS were origirally 
designed to be two subsystems of FCS. Three areas of feasi- 


bility were examined: 


a Technical 
eee cost /Benefit 


Bi Tine 


Positive conclusions were drawn 2bout the feasibility of all 
three areas. PRC did recognize the interrelationships bet- 
ween cost and time and premised their positive tine 
feasibility conclusions upon adequate steady funding. 

PRC compared the relative e¢ase of operating the 
AQMS to the labor intensive Manual Quality Monitoring System 
and called the difference one of the benefits. The improved 
accuracy was also considered a benefit. Ere «contractor did 
not try to guantify the vaiue of these benefits. The amount 
of risk evaluated for the project was consistently rated as 
low. Appendix (A) provides a listing of the additional 
eqjuipment and software required to develop the AQMS and the 


associated degree of developmental risk [{Ref. 23]. 
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b. Cost Computation 

PRC presented the following AQM cost formula in 
eiememrechhnical Objective VII section 2.2.3: 

Cost in the present context. is 


+ 
ated with the implementation o 
differential cost as follows: 


hat expenditure associ- 
f AQMU expressed as a 


= C ate 
~AQM MQM 
where ; 
C = total integrated FC syst2m cost 
AQM 
= present FC system cost 
HOM 


AS shown above, the cost for AQMS was d2termined 
by subtracting the cost of the old manual systen from the 
estimated cost of the automatic svstem. These costs were 
identified in Appendix (B). The exhibit provides a detailed 
listing of the additional hardware and software required tc 
develop the automatic system and the estimated cos* associ- 
ated with each item. 

Swerada2tional Cost Factors 

In addition to the three feasibility studies 
mentioned above, it would have been beneficial to include a 
Seerton Of study on organizational feasibility. This séc- 
Smonewould quantitatively evaluate the difficulties which 


the organization (ship) could 2xpect when imuplementing th 


i 


wD 


proposed system. 


The cost of implementation can becom2 quite sev- 


y 


ere if the sailors view the new system as a threat to their 


cl 


Security. These feelings often develop because the sailor 
was not trained in the operation of the new systen, and he 
feels his position of knowledge and authority is in jeo- 
pardy. The sailors may respond to the perceived threat wit 
either passive or active resistance [ Ref.24]. Any resis- 
tance to a new system will invariably cause ovooth delays in 


implementation and increases in the final project cost 
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RiiOlghweit 12S Sorten difficuilzt to accurately 
anticipate the exact amount of resistance which will be 
encountered and the resulting cost, an attempt must be made 
if the project costs estimated are to reasonably resemble 
the actual cost. MPDS experienced its share of operator and 
maintenance personnel passive resistance, and it is reason- 
able to conclude that the FCS would also have been received 
by the ship's crew with mixed feelings. 

A comprehensive cost/benefit analysis would also 
have estimated the cost of training the fleet sailors to 
operate and maintain the proposeji system. Appendix (B) and 
Appendix (C) do not address these costs. These areas nad 
the potential to become very costly for severai reasons. 
The fact that the FCS project was unigue to ths Large 
(C VN-6 8) class carriers would have made some additional 
training activities necessary. New instructors would haves 
to be trained, class training plans and lessons would have 
to be prepared, and training materials would have to be pur- 
chased. All of these erforts and expenses would have been 
for very small classes and would have to be completed before 
gualified personnel could be sant to the ship to operate the 
new system. 

Prie@wcmilecmoGm of cONputing the cost by Ssubtracc- 
meee CcOSt Of the MOM from the cost of the AQMS may no* 
have revealed the full cost difference because AQMS was 
designed t9 utiliz2 existing MPDS equipment. Tas ei tzda- 
tion imposes a cost upon the entire system in the form of 
either reduced performance or smaller reserve capacity avai- 
lable for future growth. 

In order for the Navy to have made a completely 
knowledgeable decision about the feasibility of the proposed 
project, it would have been necessary to identify ali of the 
@95t>s, (including cost of wsing existing systems), and to 


assign quantifiable values to the benefits. 
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3. Report Generator 
Another area of the MPDS project development which 


experienced excessive growth was that of reports which were 
generated or could be retrieved at the remote locations. 
The military specifications addressed this issue in several 


locations. 
e and retrieval capabilities for long-tern 


: < Shall be possible <*o retrieve all or 
Geeportaons Of tne log intormation either on 
Sie wien tae operator onputs a Tequest to the 


Pre following portion of the specifications provides 
a general framework for the types of information which the 
system would be required to accumulate and disseminate: 

See 2.2-5 Automated message accounting shail include: 

(a) Attachment of unigue system message numbers for 
accounting and retrieval purposes. ; 

b JOurnalling of meSsages for accounting purposes. 

fe Exthacting ©f£ Statistical data from message 
Et Special accounting for top secret message deliv- 
ery. 

To determine the type of reports required and ths 
elements of data which have to be accumulated and stored, 
the project office consulted with the users. That which 
resulted was a system which was originally developed to pro- 
duce 47 different reports [ Retr. Zoe This placed a heavy 
burden upon the entire system and greatly increased the 
amount of secondary storag2 required by the systen. These 
reports were printed at periodic intervals but could also be 
retrieved upon demand by the users at their terminals, pro- 
vided the requested information was within the security 
Cange of the user's terminal. inttially, every user could 


retrieve any report contained within the system. Since 
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retrieval of long routine reports during peak message load- 
ing periods severely deqraded csverall system performance, 
and a genuine need to Know cou COM a 


ld not be substantiated f 
terminal retrieval request, future changes to 4PDS tres- 
memee=ed C2port production to scheduled runs unless special 
off-line requests were submitted and approved [Ref. 26]. 

Recent software changes which have been released to 
the fleet have corrected many of the problems with the ini- 
tial report package. These changes have limited both the 
Content and distribution of several periodic reports.Surveys 
o£ the fleet user groups have resulted in adding important 
tracking programs which generate reports on various aspects 
of system performance. 

One, recently added, provides critical information 
to the Tommunication Officer about system message volume 
during peak loading periods. This data was either missing 
memecue OLiginal 47 reports or it was obscurely buried where 
it could not be used or readily accessed by personnel who 
needed the information [Ref. 27]. It became evident that 
Eee initial querying of the users produced an inaccurate 
composite of their requirements. The reports which MPDS 
produced resembled what the user thought that they wanted 
rather than what they truly needed. 

This lack of user understanding of his actual 
requirements became apparent in the development of the JUI-9 
remote receiver/transmitter user terminal. Seventeen func- 
tional buttons were designed into the terminals ‘to satisfy 
the users! requirements. Usage patterns have shown that the 
Operators seldom use more than six of the functions. Five 

€ the other functions were used by the maintenance person- 
nel. The net result was six user specified functional 
Capabilities designed into the system terminals which were 
mee productively utilized [Ref. 28]. 


ZS 


Dae LEoltiNG 


ee Broadcast Screening Test objectives 
Special testing of the MPDS broadcast screenin 
mma 


Bre 


capability was conducted by Naval Electronic System Co 
Southwest Division (NAVELECSYSCOMSOWESTDIV) at the MPDS test 
bed at NELC on May 14, 15, jomanra 182) "of 1973. The total 


n 


test time was 28 hours. Excerpts of real world live traffic 
were taken from four different geographic broadcast areas in 
the Atlantic, Eastern Pacific, Western Pacific, and che HMed- 
iterranean,. The primary objective was to test the system's 
ability to correctly compare the addresses of the various 
broadcast messages against the addresses contained in the 
MPDS guard list (GML). The GML contained approximately 150 
addresses [Ref. 29]. A second test objective was to deter- 
Mine how accurately the system could automatically tread and 
distribute the incoming message to the appropriate remote 
terminal. 
fey seem Inperovement fests 

Several System Improvement Tests (SIT) were also 
conducted by NAVELECSYSCOMSOWESTDIV. These SIT's were given 
t> evaluate the effectiveness of modifications made ‘to the 
hardware/software subsystem. Numerous modifications were 
made to the system for the purpose of resolving Problem Work 
Sheets [Ref. 30]. 

3. Users Involvement in Testing 

The Broadcast Screening Test and SIT both used Nia- 
itz (CVN-68) crew members to operate the system. Jett Zing 
the future operators of the system for test operations pro- 
vides many advantages to the project tean. Sitsa. Le 
provides them with an excellant opportunity to train the 
future users in the proper operation of the equipment. It is 
also an excellant opportunity to instill in them valuable 
confidense in the systen. This confidence can b2 a very 


important advantage to the project tean during the 
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implementation phase {Ref. 31]. TievShbi ric OL COODeration 
and friendship which often developes between the developer 
and fleet operators during the testing pnase can goa long 
Way toward over coming the skepticism and resistance which 
often plagues projects in later phases. Finally, the project 
team can receive important feedback from the operators con- 
cerning Operational difficulties and Constructive 
Suggestions for system improvements. 
4. Restrictive Testing Procedures 

Although the primary objective of testing the droad- 
Saecescreening capability of MPDS was fulfilled, the results 
of the test were obtained under very restricted conditions. 
Had they been obtained under Simulated or actual operational 
conditions, then th2 project tean would have known how the 
system would function when it encountered the technical and 
human stresses associatei with fleet operations [Ref. 32]. 
Message and report retrievals are two operations which Sig- 
nificantly increase the stress upon the system. Neither of 
these functions were permitted during the Broadcast Screen- 
ag Test. experience has shown that the combined effect of 
these two processes can Seriously reduce the overall effec- 


tiveness of system performance. 
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IV. INTEGRATED LOGISTIC SUPPOR 


A. Beeront ACTIVITIES 
mer © CDS SASD 

Pie 97 See BeEDSSASD Was Originally tasked to provide 
life cycle maintenance for the Message Processing and Dis- 
Peabution Systen. VOetaciiieate this Ssupponry, a special 
Suite of equipment, (identical to the MPDS equipment onboard 
Meomiametz), was installed at FCDSSASD [Ref. 33]. 

fee = NISTC 

In 1979 the Naval Telecommunications Systems Inte- 
gration Center (NTSIC) assum2ea life cycle maintenance 
Bespensibilities for MPDS [Ref. 34]. NTSIC has a duplicate 
model of the MPDS hardware and software which is presently 
Q@meeaed fhe USS Nimitz and USS Eisenhower. This model 
Serves aS a4 testing facility for all new software modifica- 
tion and hardware changes before they are delivered to the 
fmieeet for installation. 

NTSIC also serves as coordinator for all software 
Smamge proposals (SCP) [Reft. 35]. A Sample iist of SCP can- 
didates for MPDS software change release #10 is shown in 
Appendix (D3). This list was developed by sending guestion- 
naires to the fleet users and compiling the results. The 
candidates for change ware then discussed wit +he senior 
Sommunacations personnel from the carriers prior to the 
meeting of the Communications Change Control Board (CCS). 
Only change items which received unanimous user support and 
agreement were forwarded to the formal (CCB). Final Comman- 
der Naval Telecommunications (CNIC) approval for software 
changes is based upon the outcome of the board. NisTesus 
intimately involved with every step of this process [Ref. 
BO). e 


he Syncrotec Software Corporation 
[The MPDS software maintenance contract was awarded 


mOroyNcrotec from San Diego. The fact that many or the 
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Original MPDS software development programmers le ®t Planning 
Research Corporation (PRC), (the original softwere contrac- 
tor), and went to work for Syncrotec weighed he. vily in the 
decision to select them as the software maintena: :e contrac- 
mol. Since MPDS had unique software to perform difficult 
applications, it was important to choose a software mainte- 
nance corporation which had experience with the systen. 


Bs TRAINING 
ie initial Training 


commander Franson, who is the Deputy Director of 
NAVTELSYSIC, described the first training of the Nimitz's 
precommissioning crew as being very successful. This was 


due in part to the high priority that the project team 
placed upon utilizing every training opportunity. The Exe- 
cution Plan for Operational Capability Evaluation 
(OPCAPEVAL) stated the following training objective: 

" Every effort will be made to make, the MPDS available 


Boeke Nimitz crew for training during contingency per- 
iod. 


( 


This training was in addition to practical experience which 
the crew .members obtained while operating and maintaining 
the equipment during the scheduled test periods. Appendix 
(E) provides a schedule of events which occurred during the 
OPCAPEVAL and the long periods designated for system train- 
mag {Ref. 37}. 
2. Operational Training Problems 

After the system had been implemented and the USS 
Nimitz became operational, training deficiencies began to 
surface, These deficiencies became especially evident when 
the USS Nimitz made her overseas deployments. Dias te ap 
report from two Synchrotec software technicians, the follow- 
ing comments were made concerning training [{Ref. 38]: 


"The lasting a that remains with us however, is 
that the weakes link in the operation and performance 
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of MPDS is now unquestionably, the Operators themselves. 
Knowledge of basic communications page couls ana epoce— 
tices ({iet alone, knowledge of MPDS) was sadly lacking 
among many of the second and third class petty officers 
aoeeard ship, and until the sailors are familiar with how 
to communicate in the Navy environment, we can hardly 
expect them to become proficient at operating MPDS." 


This concern about the level of shipboard personnel training 
was also shared by the officers onboard the USS Ninitz. In 
a message to the Commander of the Sixth Fleet (COMSIXTHFLT), 


maewcommander of Task Force Sixty (CTF SIX ZERO) made the 
following comments [{Ref. 39}: 


"There is. no software expertise onboard Nimitz capable 
of providing the level of support that recent operations 
have documented as required tS maintain MPDS in even a 
Marginailly operational status. .. . The onboard. soft- 
Ware techs should be relieved by a technician quaiified 
in system restoral and installation of system fixes. 


It is clear from the above statements that the shipboard 
technicians lacked understanding about how MPDS operated and 
how to maintain the system. This leads to the obvious ques- 
fremeoL how did the USS Nimitz's training profile drep from 
its initial high state to one which can barely maintain 
Operational capability. 


fee scarcity of Instructors 


The Commander of Naval Education and Training 
eeNET), who is in charge of training conducted in the Navy, 
tease extreme difficulty finding qualified instructors to 
teach MPODS operator and maintenance classes. There are sev- 
eral reasons why this problem developed. 

a. The Commissioning sf the Eisenhower 

When the Eisenhower got commissioned, at 
required a full compliment of qualified operators and 
maintenance technicians to take ker to sea. Her precommis- 
Sioning crew did not have the advantage of being able to 
participate in the system development of MPDS as the Nimitz 
precommissioning had done. Consequently, they were not as 


well trained, and qualified personnel had to be acquired 
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from either the Nimitz or ashore. Since the training 
command had second priority to fleet units for personnel 
emer g, CNET could not obtain or retain the instructors 
that-1it needed to conduct MPDS classes [{Ref. 40]. 
b. Sea/Shore Rotaticn Problems 

The shortage of trained personnel combined with 
the expanding need for sailors who possessed MPDS operation 
and maintenance experience caused a serious extension of 
the normal sea/shore rotation interval. A sailor cculd 
Bouraneiy expect to receive orders from the USS Nimitz to 
the USS Sisenhower rather than the typical rotation asnore 
which most sailors have grown +o 2xpect. The net erfect of 
this extension at sea has been a severe reduction in the 
number of qualified personnel staying in the Navy. 

Coueecavilian Opportunities 

ioe mchtid creason for CNET belng short of 
instructors is the intense demand for individuals with high 
technical expertise in the civilian market. These civilian 
firms usually offer very high starting salaries to qualified 
personnel. Since MPDS technicians were generally some of 


Our most highly trained sailors, their market 


pens 


exceptionally high. With the rapid exodus of high 
technicians and barely anough personnel to man 
Meecs, it Was not surprising that CNET was unable =o pro 
the necessary number of instructors to conduct the coursés. 
Sebo e solution 

RYCUOUgh tralnoang is generally conducted by CNET, 
the lack of available instructors made it impossible for 
CNET to adequately train the MPDS operators and aaintenance 
personnel. NTSIC attacked the training problem in two 
areas, First, they sent NTSIC MPDS specialists onboard the 
aircraft carriers during their deployments to train them in 
Operating and maintaining the system under heavy stress. 


Secondly, they offered an 18 week maintenance course anda $ 
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week oparators course at regular ‘intervals to ovorepare 
sailors, who were ordered to the USS Nimitz or the USS 
Eisenhower, for their jobs. These courses have proven to be 
very beneficial in improving the shins' capability to oper- 
ate and maintain the MPDS with their own personnel. 


>. Alternative Design to PDS 
a. Description of NAVMACS 


al 
crews of the USS Ninitz and USS Eisenhower in the p 
operation and maintenance of MPDS have not been exp 
by fleet units using the Naval Modular Automated Communica- 
tions System (NAVMACS). The NAVMACS program provides a 
family of Automated Communications Systems sized to neet the 
needs of all sizes of ships. The classes of NAVMACS range 
from the most basic NAVMACS V1 and increases in sophistica- 
fmomeand Capability through the NAVMACS V2, V3, and V5. The 
prime advantage of this system is that the more complex sys- 
tems retain and build upon the components of the basic 
System. Appendix (F) provides an example of how the more 
advanced systems utilize the standard hardware of the simple 
system [Ref. 41]. 
b. Training Advantages of Modular Design 

The abov2 approach to systen development offers 
several training advantages over the MPDS. The training 
task is much easier because sailors who are enroute toa 
ship which has the NAVMACS V1 basic system instalied could 
be trained with students who are destined to serve on a 
NAVMACS V3 ship. This is possible because both systems 
share the same basic modules. The problems of small sized 
Classes and lack of qualified instructors which troubled 
MenS are not a problem with NAVHACS [ Ref. 42}. CNET has 
BeemeavlLe tO Success—EULly fill its instructor billets, and 
the increased size of the cl2sses has provided CNET with 


substantial economies of scale. 
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oc. MPDS Replacement Systen 
The NAVMACS V5 will offer ths sa 
processing and distribution services as MPDS. Ee 2s icur= 
rently scheduled to be installed on all ort the fu 
after the Vinson. It is also scheduled +o replace the MPDS 
units on the Nimitz, Eisenhower, and Vinson, as they undergo 
their regular overhauls. CNET will assume training respon- 


Beeulities for this system [Ref. 43]. 


on MAINTENANCE 
1. System Reliability Problen 

System reliability is one of the greatest concerns 
for users of online computer systems since the primary rea- 
son for installing such systems is to satisfy the need for 
immediate information. This need for reliability becomes 
even more important when the online system is tasked with 
Carrying tactical and strategic intelligence messages which 
may effect the wartime readiness posture of the host ship 
and any ships subordinate to it. 

The problem of MPDS reliability was addressed ina 
latter from the Commander of Carrier Group Two (who was 
embarked onboard the USS Nimitz) to the Commander Naval Air 


Pouce, U.S. Atlantic Fleet. 


Eeracite reliability was the Sree oboe deh clone). 
Mie race that reliability invariably declined as traffic 
volume rose made unreliability a particularly sensitive 
Peoplem. . . . Reliability of 99.5] is considered a rea- 
sonable standard of satisfactory performance [ket. 45]. 
2. &quipment Problems 
Many of the hardware items which were developed 
especially for MPDS became maintenance problems. Low mean 


time between failures (MTBF) and/or lack of revlacement 
parts were the two primary reasons for excessive system down 
time. Following will be a discussion of hardware problems 
Boeva-ed Specifically to the Data Acquisition and Distribu- 
felon Unit {(DADU) and to the MU 570 Drun: 
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a. The DADU 
PicCmmebaca AC@Uds ition and Distribution Unit 

feeeuye TD 1066, which functions as an input/output control 
interface unit, is uniyue in design and is considered essen- 
meereror hOrmal operations. This unit has been a continuous 
maintenance concern since the system was first installed on 
the Nimitz in 1974, The Supervisor of Shipbuilding at New- 
port News, Virginia, wrote the following comments to Admiral 
fmageabout the need for logic and control printed circuit 
@teds £or the DADU. 

No replacement cards_ are available to immediately 

satisfy Nimitz's demands when one of these . . . cards 

Baqi, #hich is often. It has become apparent that lit- 

tle eet on tion has, been iven to seca ie adequate 

provisioning for unique MPDS hardware [Ref ]. 
DADU failures have frequently interrupted normal shipboard 
message communication Since its initial installation. izs 
breakdowns have necessitated Synchrotech maintenance spe- 
@eatises to take long ship rid2s with the USS Nimitz to fix 
the DADJ and restore the system to normal operational 
Gapability. 

Operational units were not the only activities 
to suffer degraded mission readiness because of the unrelia- 
ble equipment. The Fleet Combat Direction Systems Suppor 
meeyacy Which Originally provided life cycle support for 
MPDS also experienced operational interruptions due *o BADU 
failures, Mies was due orimarziy to the lack of complete 
megistic support. The faiiures resulted in a substantial 
reduction in the unit's ability to meet fleet support 
requirements [Ref. 46]. 

MimMdnenwOL eto, 6 Capt.oA. 5. Hurt USNR, who was 
a hardware system engineer for Martin Marietta Company in 
Denver, Colorado, did an analysis of MPDS during his two 
weeks of active duty with the Naval Electronic Systems Con- 


mand. He made the following remarks about the DADJU: 


a2 
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Since only four of these DADU units presently ex 
ESQ procures replacement boards on an "as call 
This creates longer than usual replacement t 
costs around $1000 per card [Ref. 47}. 
Sat. Huff stated that an item which couid serve as a 
Peolacement for the DADU is a unit called MICS. It is cur- 
rently being used by the Air Force's Strategic Air Command 
with apparent Success. The modern circuit technology used 
in MICS is estimated to reduce maintenance cost by as much 
as 90] and greatly increase reliability. 
Cee tes 70 Dun 
MPDS was designed with two drums to provide 
added capacity and redundancy. The initial specifications 
called for a single IBM disk unit, but the contractor, Plan- 
ning Research Corporation (PRC), wisely convinced the 
Government Project Office £ the need for the increased 
speed which was available in the MU 570 magnetic drums { Ref. 
48]. The drums have also been characterized by low MTBF and 
frequent logistic problem. However, the failure of one drun 
does not force the entire system to shut down, which is what 
occurs when the DADU fails. This is because the second drum 
is capable of supporting the system in a degraded node. 
c. General Hardware Characteristics 
MPDS was designed with a trenendous amount of 
hardware redundancy. The system is programmed to gracefully 
die without interrupting normal nessage processing until the 
last spare unit collapses. thas feature Of MPDS “15 
extremely valuable when the system is 2xperiencing heavy 
loading while fulfilling operational commitments. During 
these periods, it would be very difficult to shut down the 
System for troubleshooting, so the designers made this 
procedure unnecessary by providing sufficient equipment 
Spares to allow the system to continue to operate {Ref. 49]. 
Peo Missiens to the Functional Description 
Several maintenance problems surfaced when the fleet 


users discovered that the new system did not do everything 
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that they needed. TwWOmecabeace Witch were of particular 
concern to the users were message storage limitations and 
NATO message handling. 
a. Message Storage Limitations 

The Commander of Carrier Group Two, who was 
embarked onboard the USS Nimitz, was deeply concerned abour 
the system's limited online nessage retrieval capability. 
H2 wrote the following comments in a letter to his Command- 
mmageotficer: 


The existing MPDS capacity did not provide sufficient 
online mesSage storage tO permit more extensive user 


recall of recent messages ..... hence duplicate paper 
files were maintained £0 provide copies of messages that 
had. been removed from online storage. Ten days of 


Online nessage crecall capability is considered a réason- 
able target [Ref. 50]. 


Although the system was obviously not providing adequate 
message retrieval services, it was performing up to the 
Standards outlined in the Functional Description. The fol- 
lowing is the message storage requirement contained in the 


Functional Description: 


me. |. 10 Systen messages and associated... . entries 
Eeai be Stored for approximately three days on online 
masS, storage to support, duplicate search,, message 
ia report generation and other functions [Ret. 


b. WATO Message Processing 

mye cGapabliity tO srgcess “North Atlantic Treaty 
Organization (NATO) message traffic was not included as part 
of the automated MPDS. Censequentiv,; “the USS Nimitz was 
required to process NATO traffic manuaily during a large 
part of her deployment to Europe [ Ref. 52}. Several tempo- 
rary patches were made to the system to allow for partial 
automated handling of NATO messages. The Commander of Task 
Force Sixty wrote the following to the Commander of thse 
peexth Fleet: 
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Without the partial automated NATO processing capability 
achieved by patches the task (9£ odrocessing ail of the 
Bene eee ici would have been close to 2pOssinle | Ret. 


The Functional Description for MPDS made no 
requirements for NATO automatic nessage processing capabili- 
ties. A permanent software change to allow automatic 
processing of NATO messages was installed onboard the JUSS 
Nimitz after the completion of the deployment. 

c. Message Traffic Estimates 

Naval telecommunications message ‘traffic has 
been increasing each year as the quality and speed of sear- 
vice has continued to improve. The Military Specifications 
for MPDS were written in 1967 when the average traffic 
volumes for aircraft carriers were much lower than what 
would be found in the fleet today. The following  MPDS 


requirements are taken from the Original Military 


Sweci. ication: 

3.1.14 Data rates and capacity.--The system waen oper- 
meng On-line’ shall .... be pOoSSible tc handle up +t 
2500 average messages per day and to retrisvably stores 
up to 7500 average messages. 

Peele ia Average traffic units.--Systen BT siinvol eyare = 
cesSing rate requirements herein shall e based on an 
average message length of 200 words [Ref. 54]. 


The average length of meSsageS aas increased to above 290 
words because fleet units are now sending more administra- 
tive traffic over the fleet broadcast which used to ops 
delivered by mail. 

MPDS has been reguired to process average mes- 
sage volumes in excess of 35090 m2ssages ver day when the USS 
Nimitz had the Task Force Commander embarked during major 
fleet exercises in the Mediterranean Sea [Ref. 55]. 

Peale =Etecrts OfeOperations Upon faintenance 
The urgent necessity of intense fleet operations has 
frequently been the cause for delays in both corrective and 


scheduled maintenance. During the 1976 deployment of the 


USS Nimitz, several hardware and softwar2 problems developed 
which could not be handled by the ship's maintenance crew. 
Synchrotech sent a software tsan aboard the carrier durin 
part of the deployment to correct problems and make recon- 
mendations for system improvements. Pollowing are a fe 
comments made by the software specialist concerning their 
Shipboard experience: 

It is nearly impossible to debug a software system in an 

Bae tonal Soe coments ex Soe Seles fears ey ste 

which are typically associatad wi a ag. command. The 

system cannot be surrendered t9 the exclusive use of 

prograamers to test and wees 7 + + an outage of even 30 

Minutes creates traffic backlogs untenable to the staff 

and ship users [Ref. 56]. 
It is evident from the above statement that a system with 
low MTBF would function more successfully inan intense 
Operational environment. Another way of solving the mainte- 
Mance problem is to design a system which offers a short 
Mean time to repair (MTTR). Many systems are available 
today which are modularly constructed to allow average *t¢ch- 
nicians to pull the defective module and insert a 
replacement module in a very short time frame. 

5. LEmproved Reliability 
MPDS has now been in the fleet for six years. Dur- 
ing this time the operators and maintenance personrel have 
acquired a wealth of valuable knowledge about the system. 
This increased knowledge has enabled the fleet users 0 
Maintain the system in a higher state of readiness. Aany of 
the original maintenance problems were due to the fact that 
it is difficult to maintain an unfamiliar system regardless 
of the level of technical expertise of your personnel [Ref. 
a7 ). 
Synchrotech software specialists were called aboard 

the USS Nimitz to solve several technical problems which 
appeared t9 be beyond the technical ability of the ship's 


Maintenance crew, The software specialist said the 
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Moeerowing about the magnetic drum failures in the trip 
report which they submitted: 


Magnetic drums--The message file clerks, who use a work 
area and table which is mounted ces Oe EnEEont of the 
drums, were stacking. burn bags (bags full of old mes- 
sages which are scheduled to be burned) on the floor 
Meoeely in front of the drum. #§§ This restricted the 
badly needed air circulation required Pm he MU-5/0 drun 
tO maintain a reasonable ambient air amperature, an 
the drum began experiencing intermittent errors. Remo- 
val of the bags resolved the problem {Ref. 58]. 


This is an example of how the operators learned valuable 
information about the heat sensitivit of the drums and the 
Peeemcrrculation patterns in the computer roon. this infor- 
mation should be available for future operators of the 
system and consequently rurther heat problems with the drums 
should be avoided. The net summation of these learning 
experiences is quite often a more reliable system. 

Another factor contributing te improved performance 
was the installation of 18 software releases by FCDSSASD and 
feeesrc [ Ref. Soli. These software releases have provided 
incremental imorovements *o the operating system, mainte- 
hance subsystems, and the retrieval subsystem. They have 
added the capability to precess NATG messages, accumulate 
and process useful data for periodic reports, and generally 


improve overall system performance. 
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¥ CONCLUSION AND RECOMMENDATIONS 


A. OVERVIEW 

The MPDS project history has provided a classic example 
of how failure can occur in the military computer acquisi- 
' tion process. This failure was the result of the Navy not 
giving sufficient attention to four major elements of the 
acquisition process. 

The first and primary problem was the Navy's failure to 
do detailed planning at the beginning of the project prior 
to initial developmental work. Inadequate time spent upon 
planning resulted in the project not having a well mapped 
eeuese tS follow. Cost over runs and problems with mainte- 
meee, training, and logistics could also be attributed to 
poor planning. Eighteen change releases by the Navy's sys- 
tem support activities were required to correct many of the 
problems which had their origins in the system olanning 
phase. 

Failure to freeze the design early in the project was 
another significant problem with the developmental process. 
The Facility Control System's design was permitted to change 
and grow until the system had to be terminated because it 
Was going to make the entire MPDS project late and drive the 
total cost of the project beyond acceptable linits. Project 
scheduling problems developed because no one knew when the 
FCS would be finished since it was not known what the fin- 
ished product was supposed to look like. 

Ambiguous and/or incomplete military specifications also 
Somcetlbuted to the project office's problems. The project 
office had to make design decisions on an adhoc basis with- 
out the benefit of the explicit directions usually contained 
in the specifications. The composite of these decisions was 
a system which provided too many reports of minimal value, 
terminal functions which were not used, and which couid not 


operate in a NATO environment. 
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Finally a comprehensive cost/benefit analysis was never 
performed to determine the true feasibility of the proposed 
systems. The high risk associated with the FCS was never 
fully recognized in the feasibility study. Alternative sys- 


tems were not considered in the feasibility study. AS 


fo 


result of the above, the service wasted a lot of money while 
pursuing the development of a system which never material- 
ized. The lack of alternative systems in the feasibility 
study deprived the Navy of the option to select a more 
appropriate design. Appendix (G) lists several of the alter- 
native design options which were available for 


consideration. 


B. RECOMMENDATIONS 

More time needed to be spant in the planning phase to 
prepare a comprehensive Configuration Management Plan, 
ieorning Plan, Security Plan, and Integrated Logistic Sup- 
Poet Plan. These documents would have provided yuick 
reference for the project tean to use when confronted with 
major decisions. The plans would have contained procedures 
for establishing a change control board and would have out- 
iemed che major project objectives for training, sec Ev; 
Side lOgistics. Such detailed guidance was badiy needed by 
the MPDS project team and would have prevented many of the 
Peoblems which resulted from the adhoc decisions. [Ref. 53] 

A Program Plan which provided for periodic reviews would 
also have been helpful to the project ‘ean. One of the 
functions of the review team would be to consider freezing 
the system/subsystem's design. Early freezing of the FCS 
design could have prevented that system's development from 
falling behind schedule. 

Future computer system acquisitions should place heavy 
emphasis on preparing thorough and clear specifications. 
This could be accomplished by establishing a specification 


review team consisting of both system sponsors and technical 


oh) 


userS whd will initially verify the original specification 
and who would later approve/disapprove Specification 
changes. This would have pravented many of the probiens 


which occurred in the MPDS project where the users and spon- 
sors received a product which was different than «hey had 
requested. 

Concise specifications have the advantage of focusing 
heavily upon the end product. Such focus tends to prevent 
the technicians from becoming overly intrigued with the 
technical sophistication of their system and forces them to 
concentrate on developing an and product which matches the 
Seecirication. This procedur2 would Limit or reduce the 
problem of acquiring extremely sophisticated hardware and 
software as the Navy did with MPDS because the developers 
would not be given a blank specification sheet where they 
SGouya fill in the details. 

To ensure compliance with the above objectives, Sts 
recommended that Project Sponsors include them in the Letter 
Semrnstruction (LOI), which signals the beginning of the 
acquisition process. By placing these requirements at the 
on-set of the project, they will receive the attention that 


they require at the appropriate time, 
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AQM DIFFERENTIAL COST ESTIMATES 
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APPENDIX E£ 


OPCAPEVAL TEST SCHEDULE OF EVENTS 
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APPENDIX F 
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APPENDIX G 


A. Srolki SELECTION 
ieee basic Criterion 
The most important dacision that tha Communication 
Planners had to make was concerning the selection of the 
type of system which they were going to develop for instal- 
Hacieon Onboard the Nimitz. The system had +o satisfy the 
major communications objectives of reducing human interven- 
tion, increasing processing speed, as well as being able to 
handle the extremely large volunes of message traffic nor- 
mally associated with air craft carriers and their embarked 
Pemageofficers' staffs. Important decisions had to be made 
concerning the number of manual activities to be automated, 
What functions should be placed online, and what processing 
speeds should be opotained. 
2. Alternative Design Approaches 
a. Semi-Automatic 
Pies ete DS developed Lor the UsS Oklahnona Cit; 
(cG-5) is an example of a system which satisfied the stated 
objectives while using minimal hardware and software 
resources. The automated features of this system aid not 
include remote terminal message and report retrieval ser- 
vices. Nor did it allow for remote terminal message 
transmission. 
b. Fully Automated 
The MPDS developed for the USS Nimitz offered 
Maximum automation, high processing speeds, and very high 
message processing rates. Tmepnavdware and  Soktwate were 
characterized by high interdependancies and sophistication. 
Cay HYbE1a Approach 
Many combinations of semi-automated and fully 
automated features were available for the planners to con- 
Sider. Any system which performed the 
basic automated functions of the (CG-5) systam would fall 


mito chis category. 
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3. Advantages 
a. Semi-Automated Systen 


The semi-automated system was built from exist- 
ing hardware. It took minimal time to become fully 
operational. The cost to develop the CG-5 system was rela- 
tively low. 

b. Fully Automated Systen 

The CVN-68 system offered many online services 
t> the users such as remote terminal message services [ Ref. 
60). These services have increased user productivity and 
eIymmunications accuracy. 

4. Disadvantages 
a. Semi-~Automated 

This system requires a lot of manual interven- 
tion in the message handling process. The users have to 
walk their outgoing messages traffic to Radio Central. Mas- 
sage retrievals take a relatively long time to process. 

b. Fully Automated 

The primary disadvantages are high development 
cost and maintenance difficulties due to the high sophisti- 
cation of the hardware and software. 


5. Planners! Choice 


[The planners had to make a verformance/cost zrade- 
off in selecting the communications system for MPDS. The 
decision to develop a highly automated system reflects the 


planners' emphasis on maximum performance. 


B. HARDWARE AND SOFTWARE SELECTION 

Another important area which was of concern to the plan- 
ners was hardware and software selection. Pians had to be 
made outlining policy on the use of existing hardware and 
software. Decisions had to be made concerning what specifi- 
cations would be used for items that had to be developed. 


The decisions mad@ by the planners can be found in the 
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feebesany Specification and the Functional Description. The 
results of these decisions can be observed onboard the USS 
Nimitz and USS Eisenhower. 
Weesgealize Existing Units 
The planners decided to use existing equipment and 
design where they were available, for MPDS [R2f. 61}. The 


pieces of equipment which were to be used were listed in th 


@ 


Patatacy Specifications. 
2. Develov New Units 
Another approach would have been to develop an 
entirely new suite of hardware and software. 
3. Advantages 
Weta lige Existing Units 
Several savings can b2 obtained by using 2xist- 
ing units. The project can save a lot of time and money by 
not having to develop a new unit. The amount of risk 
involved in ths development is also much lower when one has 
a known reliable unit in stock. 
b. Develop New Units 
The major advantage to developing new units is 
increase in performance. 
4. Disadvantages 
Seer rlizing =xisting Units 
The existing units may be functioning below the 
standards of the new equipment. Opportunities for improved 
performance may be lost because outdated units are nor 
replaced by more efficient/effective units. 
b. Develop New Units 
New developments often run a high degree of risk 
which could result in a late delivery. New units often run 
Meethe cost of the project. 
See idior Decisions 
Again the planners were required to make judgemental 


decisions about performance/cost trade-offs. Since new 
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units usually increased both performance and cost, and 
existing units tended to reduce project cost, the planners 
had to select the appropriate trade-offs. 

rhe planners! decision to use existing units for 
MPDS proved to be a wise one since the new units experienced 
meerocmon Logistic problems (Ref. 62]. 
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